AWS Transfer Family マネージドワークフローのスロットリングを検知してみる

いわさ

2022.06.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

いわさです。

前回、Transfer Familyのマネージドワークフローに関するスロットリングの仕様を検証し、紹介しました。

スロットルによってマネージドワークフローが実行されなかった場合は、自動で再試行されません。
よって、何らかの方法で検知したいところです。

私が検証出来た範囲では、CloudWatchの標準メトリクスにはスロットル制限による未実行は出力されません。
強いて言うと、ファイルPUT数とワークフロー実行数で差分が出るので、それを以て実行されていないと判断することは出来そうです。

また、CloudWatch Logsでは明確にスロットルによって実行されなかったログが出力されます。
このログからメトリクスフィルターを使うのが確実な感じもします。

{
    "type": "ExecutionThrottled",
    "details": {
        "input": {
            "initialFileLocation": {
                "backingStore": "S3",
                "bucket": "hoge0601trasnfer",
                "key": "user1/hoge1.txt",
                "etag": "f28339695e13a0073567e880ac43ddda"
            }
        }
    },
    "workflowId": "w-5e7112ad12dfeb5e2",
    "executionId": "0c5b03fd-3da0-4386-b9d2-a1dd4b109523",
    "transferDetails": {
        "serverId": "s-854f6c60a42643588",
        "username": "user1",
        "sessionId": "4a1d7b6e4b4a0321"
    }
}

この記事では、スロットル検知を行うためにメトリクスフィルターで検知でウォッチをしてみました。
また、すぐに適用出来るようにCloudFormationテンプレート化しています。

メトリクスフィルターを作成

前述のログ内容から、typeがExecutionThrottledの数をカウントしてみます。

AWSTemplateFormatVersion: 2010-09-09
Description: ---
Parameters: 
  LogGroupName:
    Type: String
  MetricNamespace:
    Type: String
    Default: custom/managedworkflow/namespace
Resources: 
  ManagedWorkflowThrottledMetricFilter:
    Type: AWS::Logs::MetricFilter
    Properties:
      FilterPattern: "{ $.type = \"ExecutionThrottled\" }"
      LogGroupName: !Ref LogGroupName
      MetricTransformations:
        - MetricValue: "1"
          MetricNamespace: !Ref MetricNamespace
          MetricName: ExecutionThrottledCount

このテンプレートの実行にあたってCloudWatch Logsのロググループ名が必要です。
Transfer Familyのロググループ名はサーバー名と紐付いており、以下の手順で確認が出来ます。

このテンプレートからデプロイすると、対象のロググループに以下のようにメトリクスフィルターが作成されます。

メトリクスを確認

では、実際にスロットリングエラーを発生させて、メトリクスを確認してみます。
こちらも以前検証したときと同じ方法で、JMeterで一定時間で負荷をかけます。

100秒間に300スレッドで実行してみます。
1秒間に3スレッド実行される想定です。そして、トークンバケットがたまった状態で最大100で秒間1補充されるので、50秒を過ぎたあたりからスロットリング制限によってワークフローが失敗するはずです。そして残り50秒間は2回/秒のペースで失敗する計算になるので、だいたい100前後失敗数として検知されるかなと。